DevMind：构建效能提升的“导航仪”和“发动机”，实现从数据到价值的跃迁
本文根据单虓晗老师在2022年TID大会同名演讲整理。文中图片里展示的所有数据、人名等信息，均做了脱敏处理，为随机数字而非实际数字。
本次实践总结，致力于探索效能度量领域的终极解决方案，既充分应用了业界主流的理论、方法，又从可实施落地、可产品化复制的角度，定义了四个最佳实践。
接下来，我会以字节跳动（后文中简称“字节”）为案例分享DevMind体系和最佳实践，让大家了解，如何让研发度量在公司内成功落地，不仅能获得公司内各层面各角色认可，还能进一步跃迁，成为组织级研发效能提升的关键成功要素。
问题：研发效能的“黄金三角”如何落地？
首先致敬张乐老师的“研发效能的黄金三角”，我自己也是这个模型的粉丝和践行者之一，它为研发效能提升工作，提供了体系化的框架和工作开展思路。但是，当你面对一个公司级的问题扑面而来的时候，你发现，如何推动这个三角，是很有诀窍的。
首先，最底层的效能平台怎么做，非常清晰——建设DevOps工具链，服务好公司内的一线研发人员。但是，一位CTO或者部门负责人让你帮他们提升一下研发效能，你应该从哪里入手呢？你会发现，直接看工具链，过于微观了，一线研发的关注点通常和CTO的关注点不同。目前为止，各公司主要的实施手段，就是找一个掌握了“效能实践”方法的专家，通过“效能度量”手段，一个一个发现效能问题，推动解决，驱动组织级效能提升。可惜这种模式，往往落地效果不理想，专业效能专家的人数、精力总是有限的，很难承担大规模组织下的批量效能分析、驱动工作，尤其是千人以上的组织，往往就是小马拉大车，死活拉不动的结果。
DevMind体系所要解决的问题，就是如何让效能实践+效能度量这两项工作可以在线化、低门槛、规模化的开展，从而驱动这个“黄金三角”快速运转。
解法：DevMind体系
思路
DevMind的核心思想，相信大家在我之前的分享里已经充分的了解，有2个要点：
从技术、产品的角度，构建一种“专家系统”：收集研发数据，并用一种标准化、工程化的方式，将专家的经验转换为数据，最终输出洞察结论、建议，给非专家的用户，达到可规模化服务的效果。我称之为“导航仪”。
从落地实施的角度，构建一种“多边平台商业模式”：同时服务公司内多角色（领域专家、QA、PMO、Leader等），形成一套多角色在线化分析、改进、协同的生态系统，从而实现自组织、自驱动的数据驱动提效模式。我称之为“发动机”。
你手握这套效能提升的“导航仪”和“发动机”，就可以快速的、有力的、持续的，推动组织级各团队研发效能提升。
难点
理想很美好，现实很骨感。
关于“效能度量为什么这么难”的问题，早在2021年年初，张乐老师、茹炳晟老师的相关文章就已经铺天盖地了，效能度量的“血案”、“失败案例”相信大家都已是耳熟能详。我自己也是效能度量这个领域的忠实爱好者，几年来我不论负责多大范围的事情，研发模式升级也好、智能化工具链也好，手里都会主导效能度量这样的项目，我也认真考古过业界几乎所有失败的度量项目、产品，从实践落地的角度，总结了四大难点。
大家先看这条工作流——从数据采集到最终产生数据洞察价值全过程，这其中，有四个极难逾越的鸿沟：
数据难：
首先，很多企业数据分散在工具链里，要做度量，必须打通数据孤岛，聚合原始数据，那就需要有公司授权，让各个工具愿意提供，此外，还需要获取很多公司级组织数据，比如人员、部门等等。
其次，原始数据不能直接用，还需要理解它所刻画的研发过程，并对数据进行清洗，去除脏数据，再关联人员、部门、应用等维度属性，最终校验后，形成干净、可用于数据分析的“研发数据宽表”才能使用。
最后，就是在线化不足或研发流程不标准，导致数据不可用。
比如项目需求管理常常是重灾区，有的团队需求、缺陷都在Excel里管，这肯定不行。
或者，已经用了Jira等工具了，但是需求状态常常没人管，结果一拉需求周期一看持续1年还没关闭。
度量难：
首先，一个事实如何被客观度量，本身就是一个大难题。虽然，早在1946年，心理学家史蒂文斯就发表了一篇名为《量度与量化的理论》，提出过一个很重要的观点叫“一切皆可量化”，在学术界尤其是社会科学领域早有共识，但是绝大部分人对量化的基本方法一无所知。我日常被问的最多的就是这个问题，你不是量化专家吗，研发效能怎么度量？人力负载怎么度量？用户体验怎么度量？人的能力怎么度量？字节的研发效能指标体系能否分享一下，参考一些指标过来。
其次，就是拿到了指标也不一定会用。比如，“千行代码缺陷数”在字节早已经是一个组织级的指标，但还是经常会遇到咨询，尤其还是QA人员：“这个指标适合我们项目吗？有没有基线标准？没有标准值，我想知道我负责的团队是好是坏？应该怎么判断？”。
通常来说，绝大部分做度量的项目，能跨过前两条沟壑，就已经消耗了大量的资源和精力了，但是，产出物通常就是一个“数据大盘”，对最终决策者来说，有价值，但是不高。我见过太多相似的情景，你兴高采烈的把一个做了两个月的数据大盘抛给管理者，他看了半天，结果没看懂，就说你能不能洞察出一些问题或者有价值的结论给我，所以你必须还要做数据分析，写一份有价值的洞察报告，来影响决策，这样他才会认可价值。
洞察难：
咱们研发效能领域的很多专家，虽然会数据分析，但是毕竟不是专业数据分析师，很多数据分析技巧是不足的，但是想体现价值、驱动问题改进，至少每个月必须做分析，出分析报告，这就导致整个过程极其痛苦，要拉数据，看大盘，验数据，跑算法，还要确认具体问题原因。投入大，成本高，最关键的就是，分析报告的结果常常也达不到决策者的预期，总是感觉数据有是有了，但是就是“差点意思”。
批量&高频服务决策难：
最后一点就是很多度量项目，就算有既懂研发又懂数据分析的专家配合，也是1-2个人的力量，而项目的风险在于，投入这么多人洗数据、做系统，却很难在公司规模化的服务。
首先，每个业务线、部门，都会有一些定制的诉求，不同发展阶段关注的研发指标肯定不同。
其次，人的需求是永无止境的，月度汇报满足了，他还想要周甚至每日看。
所以，要达成这种规模化能力，必须要依靠产品作为杠杆来规模化服务公司内所有研发分析场景。唯有这样，研发数据的价值才能得到最大化体现。
方法与实践
因此，我结合几年来在各个大型企业的落地经验和成功案例，为DevMind体系补充了四个最佳实践及配套的产品与解决方案，希望可以帮助各个企业跨越这四道鸿沟，持续升级，最终实现从数据到价值的跃迁。
实践1：数据——研发数据中台
方法
这个阶段的目标就是要打通研发数据孤岛，沉淀稳定、高质量、可用于数据分析的“研发数据宽表”。
目前主要有2个主流方法：
方法一：内部开放研发数据，服务少部分懂数据人（比如QA、PMO），依靠“群众的力量”，打磨数据，最终沉淀出一些稳定的研发数据宽表。比如，BAT的研发数据最早就是使用这个策略，面向公司内所有业务线开放，最终几年的时间内沉淀了一批公司级的研发数据宽表。这里不推荐的做法是直接开放原始表，原始表的开放会导致数据的二次加工，数据宽表最终就分散在各个团队，数据模型无法被统一，后期极难整合。
方法二：不开放研发数据，基于宽表提供各类数据分析报表、大盘，满足各内部团队的研发数据需求。比如蚂蚁集团最早就是使用这个策略，把研发数据宽表接入到BI数据分析平台，创建一些通用的报表，让各个团队来使用。这里不推荐的做法是直接开发可视化大盘，大盘设计的指标比较死板，而且研发投入重、迭代速度慢，很难快速响应用户蜂拥而来的数据需求，投入产出不成正比，常常就倒在建设的路上。
这里重点介绍一下字节的做法，业界说字节比较“卷”是有道理的。一般来说，用户要说我想要一个椅子，技术人员会精准评估需求、尽量裁剪，最后做一个3条腿的小板凳，你先用着。而字节的技术会说，除了椅子，你可能还想要一个餐椅、吧台椅、小板凳，那我给你做一个生产各种椅子的流水线吧，到时候想要什么椅子你自己生产。所以字节的实践，不仅清洗了数据宽表，还要配套做一个ABI（智能数据分析）型产品，服务公司内所有研发数据分析人员。
技术&产品
如图所示是字节这个阶段的技术、产品架构，这款子产品，我们称之为“度量（Measure）”，它服务的用户场景，主要就是分析研发数据的人员。
案例
接下来，为大家展示我们在2020年之前一直在使用的两板斧：
宽表到图表：用户可以把宽表的字段，快速加工成一个可视化图表，直接用。而且，与传统ABI平台不同，研发数据尤其需要下钻到明细，因此，还很贴心的支持明细下钻能力。
图表到大盘：用户可以把配置的图表，组合成1个大盘页面，增加全局筛选条件，用于日常的数据分析。
效果
如上图所示，就用这两板斧，我们像收集龙珠一样，几乎集齐了公司内所有主流研发工具的数据，甚至还有一些业务的数据，同时，又召唤了神龙，直接服务公司内所有能分析研发数据的人员，积累了大量的图表、大盘、核心用户群。数据的特点是“越用越准”，因此，这种“众人拾柴火焰高”的方式，帮助我们快速的淬炼出了高质量的研发数据宽表。
实践2：度量——研发指标体系
方法
这个阶段的目标就是要沉淀全公司专家经验，建设专业、统一、标准、可工程化实现的研发指标体系。
目前的主流方法就是基于研发过程模型搭建指标，以及，按“GQM”（G:目标 - Q:问题 - M:指标）[1]的逻辑，通过目标分解、问题追问的方式来保证指标的有效性、实用性。这两种方法，今年张乐老师、任晶磊老师在多次大会分享中都已经讲的比较透彻了。
而DevMind的关注点则是，在这些方法框架之上，有没有可以标准化、可落地的最佳实践，能降低指标的设计门槛，让好指标可以持续的被设计、生产出来，快速投入使用。这两个实践分别是：
研发指标流水线：查理芒格有句话我特别喜欢“只有当人类发明了发明的方法之后，人类社会才能快速发展”，大部分人都以为我们为字节建立的研发指标体系是一堆一堆的指标，而实际上，我们建设的核心是能持续产生好指标的方法，是一条好指标的生产流水线。在我看来，这个能力更为重要，尤其在大公司，从来不缺度量经验，缺的是让各个领域专家能标准化、结构化的沉淀度量经验的方法和平台。
研发指标即代码：流水线上设计出来的指标，不需要再排期做数据研发、等1-2天跑数据，而是配置后，直接代码化，随修改随生效，拿来即用。
研发指标流水线
如上图所示，这就是我们所使用的设计方法，想设计出一个好指标，其实是非常难的：
体系建模：需要对公司内的基本研发过程、问题域、评价角度有清晰的定义，在这里既要符合业界基本软件研发的一致性，又要匹配公司内的实际情况，这就需要依赖大量的软件工程知识。
指标设计：这里需要用到大量的数据分析领域知识+“GQM”方法，我结合1个例子简单讲解一下：
问题定义：有点像产品需求分析，比如你要度量提交团队MR提交的质量，那么你至少需要了解MR提交这个行为是什么含义？度量谁？（人？还是团队？）以及度量的目标是什么？
量化分析：你需要先结合经验提出假设——MR中代码合并之后的每个工程任务的成功率的平均数可能是一个好指标，那么你就要探查数据，运用一些统计学知识，来判断其合理性。
指标定义：指标是用来做分析的，那么你的指标定义就不仅仅1个计算公式，还需要定义：
分析过程中可能用到的正常 / 异常基线、分析维度。
可视化过程中可能用到的展示维度。
指标实现：这里主要就是数据研发、数据科学和数据可视化的领域了。
研发指标即代码
如上图所示，这次的突破是我们优化了OneData的方法，直接取消了数据应用层（ADS），让所有的指标配置后，全部SQL化，在各个场景中应用。既减少了数据加工生产的等待过程（一般ADS数据要T+1产出），又让指标默认可支持明细下钻，并确保指标统计数值和指标明细的一致性。
当然，这对产品、技术实现都有非常大的挑战，因此我们投入很大精力，重兵打造了一套完美的、全新的“指标中台”。
技术&产品
如图所示，这个阶段新增的子产品称为“指标中台（Platform）”，它服务的用户场景，就是能按标准方法设计、配置指标的各个领域专家。
除了产品本身的设计，它底层多了一个项核心技术叫“查询引擎”，也是我们的核心专利之一。它兼顾了灵活性和性能。灵活性在于，它可以将所有配置的指标，在消费时，结合具体的可视化展示效果，快速合成各类图表。同时，又具有缓存能力，确保指标在使用过程中，保持极高的性能，让用户几乎感知不到所有的这些展示都是“实时查询”出来的。
案例
单指标配置：大家可以看到左边的工作区是研发数据宽表，中间是把宽表的字段组成成指标，相关数据口径都在里面，右边则是指标本身的属性，包括基本配置、分析配置、分析基线配置、以及扩展配置（包括推荐给用户的改进方案或案例）。
多指标综合模型配置：也可以把各个指标进行组合，公式化，聚合成多指标综合评价模型。
查看指标：指标配后，会即刻自动生成指标分析以及对应可视化图表，直接使用。
效果
如上图所示，这个实践的效果，就是公司里各领域专家的积极性被充分的调动了起来，我们每个月都会接入和打磨几个领域（比如项目管理、流水线、测试、实验、产品等），历经半年多，基本就统一了公司内核心领域的研发指标和标准，并且全部在指标中台中配置即实现，供用户高频使用。
实践3：洞察——研发数据分析
方法
指标有了，但这么多指标，到底应该如何用、如何分析出问题呢？接下来，在“GQM”方法的基础上，从可落地的角度，介绍2个DevMind最佳实践：
指标分析模型：解决指标太多如何看、如何分析的问题。
指标自动洞察：帮助不太擅长数据分析的效能专家实现最大限度的自动分析。
指标分析模型
如图所示是数据化解决问题的一般思路：对于某一个领域的问题，我们用“结果指标”刻画“目标”，再通过对“结果指标”的数理分解，或者对“过程模型”的逻辑分解，找到一系列“过程指标”，最后，通过“过程指标”找到可执行的改进措施，持续优化，达成“目标”。
举个具体例子，比如我的目标是要健康，虽然目前医学上没有足够的指标来衡量健康，但是心血管疾病医生发现减肥可以极大的降低发病率，因此首先会把体重、体脂率、腰围这3个指标当成观测是否健康的结果指标。之后，再通过对3个指标的分解，以及对人体的治疗经验，就有了一批过程指标，比如每日运动的步数一般建议不少于10000步，每周运动时间一般建议不少于3次，每次40分钟等等，这便有了对应的改进措施。这就是领域专家们从实践中淬炼出来的“知识”，如果你也想保持健康，你就可以先拿这套指标体系测量一下自己，找到问题，进行自我改进。
这套分析方法隐含了数据分析中一个很实用的技巧，叫“启发性分析”，这种分析主要依赖一种指标间的逻辑关系，一般来说，专家经验形成的这种逻辑关系，因果性更强，远大于数据上的相关性。所以，在有较好的专家经验加持下，其实不太需要太复杂的奇技淫巧，比如线性回归、K均值算法等等，只需要在专家选出的有限指标间反复分析、下钻就好了。所以，你要问数据分析有没有捷径？是有的，最朴素的、最简单的方法，往往最实用。
下面列举几个我们常用的指标分析模型：
研发效能：主要用于定义和拆解研发效能，支撑公司级的宏观分析和诊断。
研发交付效率：这是项目管理领域沉淀的经验，是业界“流效率分析模型”的具体化。
DevOps工程效率：工程能力提升主要应用的模型，熟悉DORA的同学应该都不陌生。
指标分析模型，其本质就是沉淀和清晰表达了某个垂直领域的目标定义、问题量化、治理改进的完整解决方案。相比原来那种先分类（比如质量、效率、工程能力等）再直接平铺一堆一堆指标表达方式，视觉上有点类似，实则是一个完完全全的倒转，这种梳理，真正的让目的、手段、措施分离，分别回到了各自的位置。
所以，我的建议是，任何用量化方法解决问题的领域，都有必要认真的总结、沉淀、打磨自己的“指标分析模型”。
指标自动洞察
“指标分析模型”的能力是将目标按某种逻辑分解为多个指标，最终转换为指标分析问题。
“指标自动洞察”则是让指标具备自动分析能力。（备注：指标，包括了数值型、除法型、平均数型、多公式复合型等多种类型）
先用1个例子看下1个指标的人肉分析通常是怎么做的：
如上图所示，这是一个看起来非常简单的指标“流水线平均运行时长”，从分析结论看，这个业务线明显很差，而且也找到了明确的原因，就是在几百个Job里，找到了关键影响的Job“构建Release包”，并分析出了原因和优化措施。
接下来，我们解构一下这个分析过程：
指标定义：这里主要用到了一些数据和统计的方法，获取到了准确的指标，这是一步前置工作，所以暂时可以忽略。
描述型分析：这一步的目标是客观描述现状，并形成评价好坏的观点。因此需要确定对比基线，比如是和自己历史水平比还是和其他同类APP对比，此外还要再综合判断趋势变化，最终才能形成1句观点。
诊断型分析：这一步的目标是找到谁影响，这里就需要在多个可能的影响维度间反复分析，比如是否是某一个团队影响了？而且还不能只看平均数，因为团队A的时间最长，但可能只有1-2个流水线任务运行，对整体影响很小。而团队B的流水线任务特别多，占总体比例超过50%，那这个团队的平均数只比整体低5%，也会对整体造成了很大的影响。这个案例中，我用了一个很常见的“土方法”，叫“四象限分析”，综合看每个任务的运行量和平均时长，找到量又大、平均数又高的，最终锁定了有问题的任务。
根因分析、给出建议：到这一步，数据范围已经缩小到很精确了。对于这个例子就是已经分析到具体的Job了，那么结合工程专家的经验，就很容易找到原因和改进措施。
自动洞察能在哪些地方发力呢？就是描述型分析+诊断型分析，这两个最花时间、最依赖数据的部分，是可以自动化的。
技术&产品
如图所示，这个阶段新增的一个核心技术能力，称为“分析引擎”，它底层是一套通用算法库，上层可以快速组成成各种分析能力（多维贡献度分析、主要因素分析、异常点分析、长短期趋势分析等等），全面实现了自动数据分析、自动结论生成。
案例
接下来看下产品化之后的效果，其中有3个尤其突出且高频使用的分析能力：
描述型分析：通过将指标值和指标基线对比、分析指标的历史趋势、长短期变化，综合决策后，给出一句话结论。
波动影响：指标值在时间上变好或者变化的情况下，对其影响最大的TopN维度项。比如流水线时长这个月忽然变长了，要自动识别哪个流水行任务或者服务发生了负向变化，对整体影响最大。
主要差距：直接找到提升指标ROI最高的TopN维度项。比如哪一个流水线任务或者服务提升后，对整体影响最大，那么就优先重点提升这个流水线任务。
通过这个案例，相信大家可以了解到，很多看似花哨的数据可视化分析方法、日常充斥在各种数据分析报告里的图表，其实都是很低效的，是没有办法的办法。取数画图的人费时费力，其实大部分时候，画完图之后，用眼睛是看不出答案的，而阅读的人，尤其是没做过数据分析人，感受到的更是混乱和费解。
比如，这种折线图会特别常见。实则，它是一种数据分析的失败，画图的人根本看不出来到底是哪个维度的变化对整体影响最大（尤其是比率型、平均数型的指标），把这种图放到数据分析报告里，反而又进一步造成了视觉的混乱。
事实上，如果你已经能通过自动分析获得了想要的结论，就不再需要可视化分析这个过程了。数据可视化，只是为了让你的结论更清晰表达、更容易理解。可惜在日常工作中，这一点常常被写数据分析报告的人“选择性”的遗忘。
效果
如上图所示是这个实践的效果：
积累了10个组织级通用的指标分析模型，供各个业务线、部门使用。（补充说明：业界、公司内任何我们评估后认为有效的分析模型，都会经由指标中台的能力快速设计和导入）
所有的指标都自动具备了自动洞察能力。
它们都大幅降低了研发数据分析的门槛，让更多有价值的结论得以快速涌现。
实践4：决策&改进——研发管理驾驶舱
方法
前三个阶段完成后，其实理想中的那个“专家系统”已经被淬炼了出来，成为“导航仪”的目标基本达成。接下来的重点，就是如何成为“发动机”，让所有业务、团队，在线化分析、决策，持续发现问题、持续驱动改进。
其实，所有做度量分析的人，心里是清楚的：
“度量是手段，洞察是过程，推动有效的改进或辅助管理者做出有价值的决策才是目的”
只不过这个目标太难达成，所以，常常被“间歇性”遗忘。
但在我看来：
“只看数据，不行动，注定是一场有意义的徒劳”
你通过量化分析，把感性的判断客观化，潜移默化的帮助决策者，这当然是有意义的，但是，价值，说不清楚。如果缺少改进措施、决策点，缺少推动现实改变的行动和勇气，最终一定是竹篮打水一场空。
具体怎么做呢？按思码逸任晶磊老师的定义，就是需要不断使用“MARI”（M:度量 - A:分析 - R:回顾 - I:改进）[2]持续推动改进、螺旋式上升，配套这个过程的DevMind最佳实践叫“研发管理驾驶舱”。
技术&产品
如图所示，这个阶段新增的子产品称为“洞察（Insight）”，它以一份一份的“洞察报告”为载体，一方面面向效能分析人员提供报告的配置、编辑、评论等功能，另一方面，面向Leader提供报告浏览、改进任务录入、跟进等功能，把几个角色的日常管理场景全部串联到了一起，完整的实现了研发效能分析、改进工作的全流程在线化。
案例
这里有点小遗憾的，字节的很多业务线、专业领域都有非常深刻的洞察报告，但由于每一个数据决策的场景都是私密的，所以无法公开和大家分享。不过今天可以分享的是，我们是怎么借助产品的可规模复制的杠杆能力，来批量支撑全公司的所有决策&改进场景的。
新建洞察报告：1份洞察报告，意味着一项分析与改进工作的开始，我们为每个团队提供了快速构建洞察报告的能力，负责效能改进的人员（比如QA、PMO、效能专家等）可以依托底层同一套组织级指标，并结合自己要分析的场景，快速配置出一份洞察报告，并在线化完成数据分析，正式开启某个团队的数据驱动效能提升工作。
主要分为如下3步：
创建洞察报告
按章节选择需要的指标
对指标进行逐一分析，结合自动洞察结论，补充数据之外的观察或根因，并参考改进方案，录入改进措施。
洞察报告的浏览与驱动：每个Leader可以快速在报告上获得分析结论以及改进任务，并且可以通过评论、推送报告等方式，推动负责效能改进人员、下属进行进一步的分析与改进实施。
多业务 / 人员多指标管理：对于负责千人级业务线 / 部门的高层Leader，则会更青睐这种“上帝视角”的宽表模式，一张图可以清晰看到负责的所有业务线、关键指标的正常或异常，并直接在线化推动下级业务线的负责人，进行分析、改进与执行。
（注：人员场景和业务线类似也是类似，由于信息敏感，暂无法展示）
效果
如上图所示，我们作为公司级的平台，会从横纵2个方向来推动各级组织的洞察报告的覆盖，并评估其使用情况。
横向：我们随着指标、指标分析模型的丰富，会提供很多横向的专项洞察报告，比如研发交付效率、工程效率、代码质量等等。为负责一些公司级、业务线级横向改进工作的人员，提供推动治理的驾驶舱。
纵向：我们也支撑每个业务线 / 部门结合自己当前的阶段、Leader的管理习惯和关注点，选择关键指标定制一份洞察报告，使其成为业务线 / 部门Leader的管理驾驶舱。图中可以看到，不同业务线，发展阶段不同，关注的内容也是不同的。
依托这个“研发管理驾驶舱”实践，DevMind产品正式发布后，仅用了4个月左右的时间，就实现了全公司主要的业务线 / 部门使用同一套指标、不同的洞察报告，定期分析研发效能，持续改善。并通过横纵向的持续拉动，让业务线 / 部门越做越深入，从机械式的拉数据、贴图、出报告，逐步转变为深入洞察原因、明确改进措施、推动现实改变，也持续沉淀了大量的优秀分析&改进案例。
总结
这里总结一下，以上就是DevMind体系能快速跨越四道鸿沟的最佳实践，以及配套的产品功能。
至今为止，我们已经把所有的方法、最佳实践沉淀出了一套完整的产品与解决方案，统称为DevMind。
并且在字节这样的万人规模、网状协同、快速变化的复杂组织内，不断淬炼、打磨、升级。
从业务视角看，我们内部有一个词叫“内外一体”，就是我们是一个团队、一套产品与解决方案，既对内部做规模化服务，也对外做商业化，搭载在火山引擎上销售。
从用户场景看，我们主要负责公司内3大场景：领域专项分析与治理、研发管理辅助、研发过程辅助。
从产品视角看，我们有四个子产品模块，分别对应4个不同的用户场景：
指标中台（Platform）：面向公司内的领域专家，快速沉淀度量经验。
度量（Measure）：面向具有数据分析能力的人员，提供可以对数据源、指标进行灵活数据分析。
洞察（Insight）：面向负责效能改进以及最终决策Leader，以洞察报告为中心提供持续的洞察服务。
助推（Nudge）：这个是今天没分享到的产品，它更底层，它通过为工具链提供数据洞察能力，帮助工具链更好的服务一线研发。
从技术视角看，查询引擎、分析引擎是我们两大核心能力，这两个模块本身拥有大量的技术专利，是我们的技术核心竞争力。
未来1-2年思考
我们在公司推进过程中，大概过了半年左右的时间，各个业务线 / 部门都用起来之后，会收到非常多的强烈诉求，就是我要接入业务指标和研发指标一起管理。
业务指标五花八门什么都有，有偏向技术的性能稳定性目标，有偏向产品用户量、体验的，还有一些业务系统里特定的指标。而且和研发指标具有一定的积累、诊断周期不同，对于业务指标，有2个特点：
有明确的目标，且需要配套更及时的异常监控、问题发现、问题解决机制。
需要在数据上打通到研发过程，将业务和研发连接起来，综合观察变化，甚至还要计算业务的投入产出比。
这让我意识到，相比研发管理，业务管理对Leader来说是更刚需的，只不过目前为止，并没有一套很好工具链能把业务设计、业务管理、研发管理完全串联起来，也就是说BizDevOps还不完善，所以更多的诉求被转移到了DevMind中。
我也发现，DevMind这套产品与解决方案的通用性本身是可以“顺便”解决业务目标的管理问题的，所以在BizDevOps体系和实践完备之前，我觉得我们有责任做一下“补位”。
相信在未来1-2年，随着BizDevOps理念、方法的推广，业务、产品、研发会越来越高效、在线化的协同。届时，DevMind也会随之升级为BizDevMind，全面支撑业务→产品→研发端到端数字化管理、驱动。
写在最后
TID大会分享后，很多老师问，以你们现在产品&技术建设的高度、方法&实践到达的深度，无论在公司内还是做商业化，应该都不缺客户和场景，保持自己的高度、独特性不好吗？如此详细的分享是否有必要？
在这里统一回答大家的问题。
这些年来，效能度量在业界特别火热，各公司这个方向的项目如雨后春笋一般，甚至很多产品都直接从XX度量改名为XX洞察。但与此同时，我也看到过太多失败：
多少度量产品前期投入很大，但做出来后，用户很少，找不到正确的使用方法和价值，最后只是变成画图、看图的工具。
多少业务、研发、质量、PMO团队的度量专项，做数据的时候风风火火，真正需要做改进的时候，逐步变成例行的数据“通晒”，价值越来越低，投入越来越少，最终销声匿迹。
所以，我希望大家都可以在正确的方向上探索，至于过程、手段当然可以百花齐放、各显其能。何为正确的方向？为了避免太虚，我结合本次DevMind实践分享内容，从可落地的角度，总结了以下3点：
DevMind式的指标体系：有目标、有过程模型、有结果&过程指标、有分析方法、有应用场景、有改进方案。任何形式的单纯的指标堆砌，都是无效的。
DevMind式的洞察报告：有深入分析结论、有明确改进措施。任何形式的单纯的可视化图表堆砌，都是无效的。
DevMind式的效能改进：所有的看数据、出报告、做分析、推改进或做决策，都应该在线化完成，让数据客观、过程可追溯、结果可评价。任何形式的单纯的数据“通晒”，没具体行动落实，都是一场围着问题跳舞的数字游戏而已。
希望，星星之火，可以燎原。